1. Field of the Invention
The present invention relates generally to transaction processing systems. More particularly, the present invention relates to a system and method for representing IMS messages as XML documents.
2. Identification of Copyright
A portion of the disclosure of this patent document contains material subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
3. Relevant Technology
With the explosive growth of the Internet, most of the world's computer systems are now interconnected or capable of being interconnected. However, in order to share data, the systems need to understand each other's data formats. In recent years, the computer industry has evolved at such a rapid pace that systems developed only a few years apart use vastly different and incompatible formats. Such incompatibility problems tend to increase with the “age” differences of the systems.
The Information Management System (IMS) is one of the oldest and perhaps the most popular transaction processing (TP) systems. A TP system supervises the sharing of resources for concurrently processing multiple transactions, such as queries to a database. Anyone who has ever used an ATM, rented a car, or booked a flight, has probably used IMS.
IMS was developed by IBM in the 1960's as a inventory tracking system for the U.S. moon landing effort. Today, interfacing IMS with newer systems, particularly with systems of different manufactures over the Internet, is problematic.
As illustrated in FIG. 1, an IMS 10 typically includes two major components: an IMS Transaction Monitor (IMS/TM) 12, which is responsible for scheduling, authorization, presentation services and operational functions, and a hierarchical database 14, DL/1. Both components are independently configurable. For example the IMS/TM 12 can use a relational database, such as DB/2, rather than DL/1. The various components of an IMS 10 communicate via the MVS operating system 16.
As illustrated FIG. 2, the architecture of IMS is divided into four regions: a message processing region (MPR) 20, a batch message processing (BMP) 22 region, an interactive fast path (IFP) 26 region, and an IMS control (IMSCTL) 24 region. The MPR 20 is used to execute message-driven applications 18. Execution of applications 18 in this region 20 is triggered by incoming messages, such as those received from a terminal.
By contrast, applications 18 in the BMP 22 are not message driven. They are usually scheduled to run at times of low system activity, such as nights and weekends. Typically, such applications 18 perform a number of predefined operations, after which they immediately terminate.
The IFP 24 allows fast and simple requests to the hierarchical database 14. Applications 18 operating in the IFP 24 bypass the normal scheduling mechanism, providing relatively fast response times. In general, IFP applications 18 stay resident even if they are not needed.
The IMSCTL 26 is responsible for overseeing all TP tasks, as well as for controlling all dependent regions (e.g., MPR 20, BMP 22, and IFP 24). Essentially, the IMSCTL 26 has three main responsibilities: telecommunications, message scheduling, and logging/restart.
For example, as illustrated in FIG. 3, the IMSCTL 26 controls one or more connected terminals 28, sending and receiving messages to and from the terminals 28. Moreover, the IMSCTL 26 logs all transactions in order to provide the capability of undoing non-committed transactions in the event of a system failure.
In addition, every time the IMSCTL 26 receives an input message 30 from a terminal 28, it schedules an application 18 to process the message 30. The IMSCTL 26 identifies the desired application 18 and puts the message 30 in the application's message queue 32. The application 18 processes the message 30 and responds to the originating terminal 28 by placing an output message 30 in the terminal's message queue 34.
As illustrated in FIG. 4, an input message 30 typically includes the following fields:
LL Length of the message segment.
ZZ Reserved for IMS.
TRANCODE Transaction code that identifies the application 18.
Text Message text sent from the terminal 28 to the application 18. The structure of an output message 30 is similar, except that the TRANCODE field is missing.
In general, messages 30 belong to one particular IMS application 18. When the application 18 is implemented, the format of the message 30, including the types and lengths of its fields, must be defined. The format of a message 30 is referred to herein as a message definition 38. Message definitions 38 may be implemented using various programming languages, such as COBOL, assembler, PL/I and Pascal. For example, the message definition 38 illustrated in FIG. 4 is implemented in COBOL.
Unfortunately, IMS messages 30 are in a proprietary format, whereas the Internet is based on open standards, such as the HyperText Markup Language (HTML), a variant of the extensible Markup Language (XML). As a result, interfacing IMS with remote systems via the Internet can be difficult. Accordingly, what is needed is a system and method for representing IMS messages 30 in an open, interchangeable format, such as XML.